LAYER 1: EXECUTIVE CONTEXT (Cody\ s Notes)

LAYER 2: CORE PHILOSOPHY (The Narrative Summary)

Core Philosophy

A "Feature Factory" is an ecosystem where the assembly line of shipping features has become the goal itself, detached from any meaningful impact on the business or the user. Velocity is celebrated, but value is ignored.

1. Red Flags of Output-Focused Cultures

• Lack of Iteration: Once a feature launches, the team moves immediately to the next one. There is no "Version 2" because the roadmap is already full.
• The Success Paradox: "Shipping on time" is the only celebrated metric, regardless of whether the feature solved the problem.
• HiPPO Decisions: Priorities are set by the "Highest Paid Person’s Opinion" rather than customer evidence or strategic alignment.

2. Structural Sickness

• The "Requirement" Culture: PMs spend their time writing detailed specifications for features that have already been decided by others.
• Lack of Context: Teams don't know why they are building what they are building, other than "it's on the roadmap."
• Resource Shouting: Teams with the loudest leaders get the most resources, rather than the teams with the most impactful opportunities.

3. Tactical Shifts

• Theme-Based Roadmaps: Move from a list of features to a list of problems to be solved or themes to be explored.
• Post-Launch Measurement: Mandate a "look back" on every launch to measure the actual impact vs. the expected outcome.

Quick Reference Checklist

• Do we measure the impact of features after they launch?
• Is our roadmap a list of features or a list of problems/outcomes?
• Is there a "culture of celebration" for shipping, but silence on results?
• Do we have high technical debt caused by "sprinting" to meet arbitrary dates?

Generated for the Product Leadership Growth Program.

LAYER 3: FULL REFERENCE (Raw Article Content)

Source: 12 Signs You’re Working in a Feature Factory

(Note: This was written in 2016. I recently — in late 2019 — wrote a post about some things I’ve learned since then.)

I’ve used the term Feature Factory at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

1. No measurement. Teams do not measure the impact of their work. Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work worked
2. Rapid shuffling of teams and projects (aka Team Tetris). Instead of compelling missions or initiatives, teams deal in feature and project assignments. Chronic multitasking and over-utilization
3. **Success theater** around “shipping” with little discussion about impact. You can tell a great deal about an organization by what it celebrates
4. Infrequent (acknowledged) failures and scrapped work. No removed features. Primary measure of success is delivered features, not delivered outcomes. Work is rarely discarded in light of data and learning. Often the team lacks the prerequisite safety to admit misfires
5. No connection to core metrics. Infrequent discussions about desired customer and business outcomes. Team cannot connect work to key business and customer satisfaction metrics. Impossible to connect iterations to “what matters most”
6. No PM retrospectives. Product managers do not conduct regular retrospectives on the quality of their product decisions and compare expected benefits to actual benefits. Developers have “passing tests”, but product managers do not. Product managers view velocity and output as their key performance indicator
7. Obsessing about prioritization. Mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (deciding if it was, in fact, the right thing to work on). Prioritization rigor is designed exclusively to temper internal agendas so that people “feel confident”. Lots of work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data. Roadmaps show a list of features, not areas of focus and/or outcomes
8. No tweaking. Once work is “done”, the team moves immediately on to the next “project”, leaving no time to iterate based on qualitative and quantitative data
9. Culture of hand-offs. Front-loaded process in place to “get ahead of the work” so that items are “ready for engineering”. Team is not directly involved in research, problem exploration, or experimentation and validation. Once work is shipped, team has little contact with support, customer success, and sales
10. Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint
11. Chasing upfront revenue. Features are implemented to close new deals. While not inherently wrong, the economic justifications are often flimsy (at best), and fail to account for the non-linear increase in product complexity (you make the quarter, but you pay for it many times over later). Again, this reinforces the idea that features are the unit of value measurement. Product decisions lack a sound economic grounding
12. Shiny objects. Low visibility for refactoring work and debt work-down. Low visibility for overall value delivery capabilities. As mentioned, primary measure of success is new feature output. Little appreciation for the health of the whole product as opposed to shiny new objects. Little awareness around impact of new features on usability (and maintainability and extensibility) of existing product For translations of this post see: Korean

I’ve written about addressing this problem. Check out these posts:

Generated for the Product Leadership Growth Program.